Some keyboards (like Aula F75 and Apple keyboards) have function keys (F1-F12) that don't work properly in Linux because they're incorrectly detected or configured to prioritize media keys over standard function keys.
hwinfo --keyboard may show the device as "Apple Aluminium Keyboard (ANSI)" even for non-Apple keyboards
Starts the CurseForge desktop app for Windows with the ad panel on the right hidden. No CurseForge files are changed.
CurseForge-NoAds.ps1 box below.
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
Honest answer to "what was your prompt?": there was no single prompt. It was a conversation between a director (Ahmed) and Claude Sonnet 5.5 in Claude Code, plus one repeated brief that Claude gave to sub-agents (one agent per scene). Both are here, word for word.
Sonnet 5.5 is out, I need a video. One approach is storytelling. Look at my video about Opus 5.5 on the YouTube channel Ahmed T'aide, it had a small success. Look at the comments and tell me which video I could make.
OK, let's also look at the comments of this video: <a competitor's Sonnet 5.5 tutorial>
Let's go with the one that answers every question. We do storytelling from ZERO frame. We do the same thing again, but this time we add humour, emotion, and above all the prompts and my working method. Start by writing the script, and we'll use ElevenLabs v4.
TL;DR: CPython's do_lookup in Objects/dictobject.c never checks that a dk_indices value is less than dk_nentries. Combined with a dict-watcher reentrancy bug in insert_combined_dict (python/cpython#154710), this enables an out-of-bounds heap write and read through CPython's core dict implementation. Confirmed on Python 3.13.12 with SIGSEGV.
This writeup applies the ZOP (Zend-Oriented Programming) technique — originally presented at BlackHat USA 2026 against PHP — to CPython's dict internals. The same "index forgery" principle works because CPython's compact dict uses an architecturally identical design: a small dk_indices[] array of integers indexing into a dense dk_entries[] array of {hash, key, value} structs.
A write-up for a friend. This is the setup I have converged on after about a year of running Claude Code and Codex CLI on real products, some of them with the agents working for days at a time while I sleep. It is generic on purpose. Where I quote numbers they come from my own repos, measured on 2026-09-23.
The short version: one Linux box, a terminal multiplexer built for agents, a written contract per repo that tells the agent how work is done, and a loop of grill → issues → orchestrated build → adversarial verification → merge → docs. The agent
| import {test} from 'node:test'; | |
| import assert from 'node:assert/strict'; | |
| import {spawnSync} from 'node:child_process'; | |
| const runInFreshNode = (scenario) => { | |
| const program = ` | |
| const fail = (message, ms = 5) => new Promise((_, reject) => setTimeout(() => reject(new Error(message)), ms)); | |
| const succeed = (value, ms = 5) => new Promise((resolve) => setTimeout(() => resolve(value), ms)); |
A Tampermonkey userscript for keyboard-first navigation through GitHub pull-request diffs.
j: move to the next viewport-sized diff segmentk: move to the previous viewport-sized diff segmentv: toggle the selected file's Viewed state and advance to the next filel: load the selected large diff when GitHub defers it